Optical Transport Network (OTN) includes a set of Optical Network Elements (ONE) connected by optical fiber links, able to provide functionality of transport, multiplexing, switching, management, supervision and survivability of optical channels carrying client signals. OTN is defined, inter alia, in ITU-T Recommendations G.709 (December 2012) “Interfaces for the Optical Transport Network (OTN),” G.798 (October 2010) “Characteristics of optical transport network hierarchy equipment functional blocks,” G.805 (March 2000) “Generic functional architecture of transport networks,” G.872 (October 2012) “Architecture of optical transport networks,” G.798.1 (April 2011) “Types and characteristics of OTN equipment,” G.7710 (February 2012) “Common equipment management function requirements,” G.7714.1 (April 2003) “Protocol for automatic discovery in SDH and OTN networks,” G.873.1 (July 2011) “OTN Linear Protection,” and G.873.2 (April 2012) “ODUk Shared Ring Protection,” the contents of each are incorporated by reference herein.
Currently, the state of the art technology for optical transport and switching systems is based on OTN, such as through G.709 and the like. One of the capabilities defined by the OTN standards is the concept of tandem connection monitoring (TCM). Tandem connection monitoring provides the ability to monitor arbitrary segments of an optical path through the optical transport and switching network. This capability is critical to the ability of an operator to efficiently manage that segment of an end-to-end path carried within the domain of that operator, independent of segments provided through other operator domains or of the end-to-end path itself. The OTN tandem connection monitoring functionality is supported through six sets of overhead information (six levels of tandem connection monitoring), each including three overhead bytes supporting bit error monitoring, trace identifier functions, and Tandem Connection Monitor (TCM) status. In addition, a TCM Activation byte was allocated to support activation of TCMs but the specific use of this byte is currently not defined.
When faults and/or performance errors occur within an operator network, it is necessary to localize the source of the problem, i.e., identify the specific defective equipment or facility, in order to initiate repair activities. Links/connections within an operator domain are today monitored using normal TCMs at their endpoints. Conventionally, maintenance activities related to fault localization are performed manually. Usually this is performed by the use of loopbacks and test sets or through direct test access where the connection is monitored and tested remotely using test sets. Loopbacks are disruptive to the end-to-end service. This can be an issue when the service is exhibiting intermittent behavior and is still providing some level of customer service. The service is totally unusable while the loopback is operational and the loopback may need to be activated for extended periods to detect intermittent behavior. Remote test access is generally only available at switching nodes, it is not provided by all equipment so its use has limitations (not every monitor point may be accessible). Remote test access, where provided, can usually be performed in monitor or split modes. The split mode has the same effect as a loopback; the service is unavailable during this state. The monitor mode is usable but requires remote test equipment and is susceptible to defects/errors within the access line itself.
Additionally, no automated means of performing fault localization currently exists for OTN equipment. A function critical to the management of an operator network is the ability to perform maintenance functions for connections through the operator domain (the domain monitoring role). This requires not only the ability to monitor the domain connection but to localize problems with the connection should they arise. Current state of the art for TCM control is to use the control plane to automatically assign TCMs based on the connection configuration during connection establishment. However, the ability to configure TCMs for service maintenance has not be addressed and there are no applications known for either automatic or manual fault localization.